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SECTION  I — ABSTRACT 

The  purpose  of  this  paper  is  to  discuss  some  organizational  aspects  of  programs  using  the  actor 
model  of  computation.  In  this  paper  we  present  an  approach  to  modelling  intelligence  in  terms  of  a 
society  of  communicating  knowledge-based  problem-solving  experts.  In  turn  each  of  the  experts  can  be 
viewed  as  a society  that  can  be  further  decomposed  In  the  same  way  until  the  primitive  actors  of  the 
system  are  reached.  We  are  investigating  the  nature  of  the  communication  mechanisms  needed  for 
effective  problem-solving  by  a society  of  experts  and  the  conventions  of  discourse  that  make  this 
possible.  In  this  way  we  hope  eventually  to  develop  a framework  adequate  for  the  discussion  of  the 
central  issues  of  problem-solving  involving  parallel  versus  serial  processing  and  centralization  versus 
decentralization  of  control  and  information  storage. 

This  paper  demonstrates  how  actor  message  passing  can  be  used  to  understand  control  structures 
as  patterns  of  passing  messages  in  serial  processing.  This  paper  is  a pre-requisite  for  successors  which 
treat  issues  of  parallelism  and  communication  within  the  framework  established  here.  The  ability  to 
analyze  or  synthesize  any  kind  of  control  structure  as  a pattern  of  passing  messages  among  the  members 
°f  * society  provides  an  important  tool  for  understanding  control  structures.  Ultimately,  we  hope  to  be 
able  to  characterize  various  control  structures  in  common  use  by  societies  in  terms  of  patterns  of  passing 
messages.  This  paper  makes  a small  step  in  this  direction  by  showing  how  to  characterize  familiar 
control  structures  such  as  iteration  and  recursion  in  these  terms. 


2 


Control  8 1 mo  taro 


SECTION  II  — METHODOLOGY 


H I — Modeling  on  Intolligent  Person 

Newell  [1962]  characterized  what  hat  become  the  conventional  metaphor  for  computer  problem 
solving  as  follows:  "The  problem  tolver  thould  he  a tingle  per  tonality,  wandering  over  a goal  net  much  at 
an  explorer  wandert  over  the  countryiide,  having  a tingle  context  and  taking  it  with  him  wherever  he 
goet.m  Working  within  this  paradigm,  authors  of  problem  solving  programs  have  often  relied  on 
introspection  as  to  methods  that  they  would  personally  use  to  accomplish  the  task.  Excellent  scientific 
work  has  been  done  working  within  this  metaphor.  Some  of  the  work  has  taken  the  form  of  writing  a 
program  to  perform  a task  which  requires  a high  degree  of  problem-solving  ability  in  a human.  Other 
work  has  attempted  to  model  how  an  individual  human  actually  performs  a simple  task  at  an 
information  processing  level. 

Research  in  any  scientific  field  is  carried  out  within  the  framework  of  underlying  theories.  A 
large  portion  of  the  research  that  has  been  done  In  the  field  of  Artificial  Intelligence  has  taken  the 
modeling  of  an  artificial  human  as  its  implicit  goal.  An  early  form  of  this  modelling  paradigm  was  the 
goal  of  constructing  devices  which  would  pass  the  Turing  Test"  By  this  test  a device  is  intelligent  if  it 
cannot  be  distinguished  from  a human  by  interaction  through  a teletype.  However,  the  Turing  Test" 
view  of  the  goal  of  artificial  intelligence  has  been  abused  In  recent  years.  Transcripts  that  appear  to  be 
Interactions  with  programs  have  been  published  that  give  a very  misleading  impression  of  the  real 
capabilities  of  the  process  that  produced  the  transcripts. 

11.2  --  Modeling  a Society  of  Experts 

Reciprocal  communication  of  a cooperative  nature  it  the  ettential 
Intuitive  criterion  of  a society. 

Edward  0.  Wilson  in  S0CI09KX.QGY 

We  are  investigating  the  problem  solving  model  of  a society  of  experts  to  supplement  the  model 
of  a single  very  intelligent  human.  We  submit  that  this  change  in  focus  has  several  beneficial  results. 
It  provides  a better  basis  for  naturally  Introducing  parallelism  into  problem-solving  since  protocols  of 
individual  people  do  not  seem  to  exhibit  much  parallelism.  The  change  In  focus  helps  to  make 
mechanisms  for  the  communication  of  knowledge  more  explicit.  Psychologists  have  found  it  extremely 
difficult  to  discover  the  communications  that  occur  in  the  mind  of  an  individual  expert  during  problem 
solving.  Also  the  Justifications  for  statements  becomes  more  explicit  since  one  expert  will  often  demand 
explicit  Justifications  for  the  statements  of  another  expert.  It  helps  make  the  goal  structures  of 
programs  more  explicit  since  experts  can  demand  to  know  why  they  are  being  asked  to  work  on  a 
particular  task  and  how  this  task  fits  in  with  other  tasks  that  are  being  pursued.  Furthermore  the 
change  should  foster  better  specifications  for  tasks  to  be  achieved  so  that  appropriate  experts  can  be 
selected  or  synthesized. 
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In  these  ways  we  hope  to  develop  the  communication  mechanisms  that  are  necessary  to  achieve 
cooperation  between  expert  modules  for  various  micro-worlds  in  order  to  perform  larger  tasks  which 
call  for  the  expertise  of  more  than  one  micro-world.  Our  work  is  attempting  to  build  on  the  analysis 
that  has  been  done  by  philosophers  of  science  in  recent  years  on  the  structure  of  the  processes  used  by 
scientific  societies.  In  particular  the  work  of  Kuhn  and  Popper  and  their  followers  provides  us  with  a 
large  stock  of  problem-solving  ideas.  The  long  term  goal  is  to  construct  systems  whose  behavior 
approximates  the  behavior  of  scientific  societies.  That  is.  the  ultimate  aim  is  to  build  systems  which 
model  the  wav  scientists  construct,  communicate,  test,  and  modify  theories. 


11-3  --  The  Aotor  Programming  Methodology 

We  are  developing  methods  to  specify  the  behavior  of  actors  (objects)  in  terms  that  are  natural  to 
the  semantics  of  the  causal  and  incidental  relationships^  among  the  objects.  That  is,  we  are  attempting 
to  develop  a transparent  medium  for  constructing  models  in  which  the  control  structure  emerges  aa  a 
pattern  of  passing  messages  among  the  objects  being  modeled. 

Towards  that  end,  we  are  developing  a programming  methodology  consisting  of  the  following 
activities: 


Deciding  on  the  natural  kinds  of  actors  (objects)  to  have  in  the  system  to  be  constructed. 

Deciding  for  each  kind  of  actor  what  kind  of  messages  it  should  receive. 

Deciding  for  each  kind  of  actor  what  it  should  do  when  it  receives  each  kind  of  message. 

Making  the  above  decisions  should  constitute  the  design  of  an  implementation.  Thus  the  data 
structures  and  control  structures  of  the  implementation  should  be  determined  by  these  decisions  instead 
of  being  determined  by  the  limitations  of  the  programming  language  being  used.  This  is  not  to  say 
that  the  resulting  implementation  should  be  unstructured.  Rather  the  structure  of  the  implementation 
should  develop  naturally  from  the  structure  of  the  system  being  modeled  working  within  the 
conventions  of  discourse  among  actors. 

Actors  are  a local  model  of  computation.  There  is  no  such  thing  as  “action  at  a distance"  nor  is 
there  any  'global  state"  of  all  actors  in  the  universe.  Actors  Interact  on  a purely  local  way  by  sending 
messages  to  one  another. 


I:  Causal  relationships  are  determined  by  physical  causation  in  activating  computational  events  whereas 
incidental  relationships  are  determined  by  the  local  order  of  arrival  of  messages  at  their  destinations. 
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SECTION  III  — THB  ACTOR  MODEL 


111.1  — Actoro 

The  basic  construct  of  our  computation  model  is  the  ACTOR.  The  BEHAVIOR  of  each  actor  is 
DEFINED  by  the  relationships  among  the  events  which  are  caused  by  the  actor. 

At  a more  superficial  and  imprecise  level,  each  actor  may  be  thought  of  as  having  two  aspects 
which  together  realize  the  behavior  which  it  manifests: 

the  ACTION  it  should  take  when  it  is  sent  a message 

its  ACQUAINTANCES  which  is  the  finite  collection  of  actors  that  it  directly  KNOWS 

ABOUT. 

We  first  discuss  actors  in  terms  of  their  physical  arrangement  because  it  makes  the  discussion 
more  concrete  and  familiar  to  most  readers.  Gradually  the  emphasis  will  change  to  a discussion  of  the 
behaviors  realized  by  actors. 

Diagramatically  we  will  represent  a situation  in  which  an  actor  A knows  about  an  actor  B by 
drawing  a directed  arc  (which  may  be  labeled  for  the  convenience  of  the  reader)  from  A to  B. 


A directly  knows  about  B as  "friend" 
B directly  knows  about  A as  "support" 
A directly  knows  about  C as  "n" 

B directly  knows  about  C as  "father" 

C directly  knows  about  D as  "door" 


Diagram  of  the  acquaintances  of  actors  A,  B,  C,  and  D 
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The  notation  (acquaintances  x)will  be  used  to  denote  the  immediate  acquaintances  of  an  actor  a. 
For  example 


(acquaintances  A)  a {C  B| 

(acquaintances  B)  a (A  C) 

(acquaintances  C)  a (0) 

(acquaintances  0)  ■ {} 

Note  that  the  KNOWS  ABOUT  relationship  is  asymmetric;  i.e.  it  is  possible  for  an  actor  A to 
know  about  another  actor  C without  C also  knowing  about  A.  Should  it  happen  that  A and  B know 
about  each  other  then  we  will  say  that  they  are  MUTUAL  ACQUAINTANCES. 

The  acquaintances  of  an  actor  are  an  abstraction  of  Its  physical  representation  Consider  for 
example  a list  L with  first  element  X and  rest  Y 


Diagram  showing  L directly  knows  about  X as  'first*  and  Y as  'rest* 

The  actual  physical  representation  of  L could  be  in  terms  of  a linked  list,  a vector  of  storage,  or  even  a 
hash  table: 


Pll«  • 
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LIN^Eb  list  vector  hash  TA  bl£ 

Diagram  showing  alternative  physical  realizations  of  L 

Actors  are  straightforward  to  implement  on  conventional  machines.  We  will  mention  a couple  of 
ways  to  do  this  in  order  to  add  concreteness  to  our  discussion.  Practical  implementations  are  particularly 
easy  to  construct  using  list-processing  languages  and  micro-processors.  Our  implementation  of  actors  in 
LISP  uses  one  cons  pair  for  every  actor.  One  component  of  the  pair  is  a LISP  procedure  which 
provides  an  entry  point  into  the  machine  code  necessary  to  implement  the  behavior  of  the  actor  when  it 
is  sent  a message.  The  other  component  of  the  pair  is  an  ordered  list  of  the  acquaintances  of  the  actor 
A similar  representation  could  be  used  on  a micro-processor  (such  as  the  CONS  micro-processor  of 
Knight  et.  al.).  A reference  to  an  actor  on  a micro-processor  would  in  general  require  one  word  of 
memory  which  consisted  of  two  sub-fields.  One  field  would  be  used  as  an  index  into  the  micro-code 
and  the  other  field  would  be  used  to  point  to  a vector  of  the  acquaintances  of  the  actor. 


The  reader  should  keep  in  mind  that  within  the  actor  model  of  computation  there  is  no  wav  to 


decompose  an  actor  into  its  parta.  An  actor  is  defined  bT  its  behavior:  not  by  its  physical 


resen  t at  ionl 
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1112  — Components  of  chc  Actor  Model 

The  actor  message-passing  model  is  being  developed  as  four  tightly  related  and  mutually 
supportive  components: 

I:  A method  for  the  rigorous  specification  of  behaviors  from  various  perspectives 
An  important  degree  of  flexibility  available  in  actor  semantics  involves  the  ability  to 
carefully  control  the  articulation  of  detail  to  be  included  m specifications  That  is, 
the  constraints  on  the  behavior  of  a system  of  actors  can  be  specified  in  as  much  or 
as  little  detail  as  is  germane.  Too  much  detail  is  distracting  and  impractical  Too 
little  detail  fails  to  specify  important  aspects  of  the  desired  behavior  The  wrong 
kind  of  detail  deflects  attention  down  fruitless  paths.  Often  the  specifications  need 
to  be  very  highly  articulated  for  some  crucial  aspects  of  the  desired  behavior  and 
less  so  for  other  aspects.  We  are  developing  a methodology  through  which  the 
desired  behavior  of  a system  can  be  specified  by  axioms  which  characterize  the 
relationships  among  the  events  which  must  constitute  the  behavior  of  the  system  At 
the  highest  level  these  axioms  are  specifications  of  what  is  to  be  done  rather  than 
how.  As  more  detailed  constraints  of  the  allowable  events  are  gradually  imposed, 
the  possible  behaviors  which  will  realize  these  constraints  become  more  restricted 
until  one  is  uniquely  determined.  Conversely,  in  order  to  demonstrate  that  a set  of 
specifications  is  satisfied  by  a particular  actor,  one  examines  the  behaviors  of  the 
component  actors  and  demonstrates  that  the  connection  of  these  behaviors  realizes 
the  behavior  that  is  required. 

2:  A system  (called  PLASMA  for  PLANNER-like  System  Modeled  on 

Actors)  implemented  in  terms  of  actor  message  passing  that  is  convenient  for  the 
interactive  construction  of  scenarios,  scripts,  and  justifications  A SCRIPT  is  a 
PLASMA  program  which  can  be  used  to  specify  the  action  that  an  actor  will  take 
when  it  receives  a message.  In  our  research  we  have  attempted  to  investigate 
semantic  instead  of  syntactic  issues  We  have  designed  PLASMA  to  be  a 
transparent  medium  for  expressing  the  underlying  semantics  of  actor 
message-passing.  For  example  the  semantics  of  the  "knows-about"  relationship  for 
actors  dictates  that  PLASMA  must  use  a particular  syntactic  rule  (lexical  binding) 
for  the  referents  of  identifiers  The  semantic  model  specifies  that  acquaintances  of 
an  actor  must  be  specified  when  the  actor  is  created  PLASMA  satisfies  this 
semantic  constraint  by  using  the  values  of  the  identifers  at  at  the  time  of  creation 
for  the  free  identifiers  in  the  script  of  a newly  created  actor  since  these  are  the  only 
actors  available  to  be  used  as  acquaintances 

3:  A mathematical  theory  of  computation  which  can  represent  any  kind  of 

discrete  behavior  that  can  be  physically  realized  Our  goal  is  to  have  a robust 
theory  whose  theorems  are  not  sensitive  to  arbitrary  conventions  and  definitions  A 
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theory  which  will  be  widely  applicable  as  a mathematical  tool  is  needed  for 
formalizing  and  investigating  properties  of  procedures.  Currently  our  theory  takes 
the  form  of  a set  of  laws  that  any  physically  realizable  actor  system  must  satisfy 
together  with  a set  of  axioms  that  characterize  the  behavior  of  a powerful  modular 
set  of  physically  realizable  actors  (the  primitives  of  PLASMA)  which  embody 
conventions  for  discourse  among  actors. 

4:  The  Event  Diaerams  presented  in  this  paper  are  a further  development  of  a 
graphical  notation  used  by  Richard  Steiger  In  his  masters  thesis  for  displaying 
relationships  among  the  events  of  an  actor  computation.  In  this  paper  we  use  them 
to  show  the  causal  and  knowledge  relationships  that  characterize  simple  control 
structures  such  as  iteration  and  recursion  as  patterns  of  passing  messages  Given  an 
outline  of  important  hypothesized  events  and  causal  relations  among  the  events  of  a 
particular  computation  (i.e.  a SCENARIO  of  the  intended  behavior  of  the  system), 
event  diagrams  aid  in  abstracting  scripts  of  modules  that  are  capable  of  realizing 
this  behavior.  For  example  we  plan  to  explore  the  abstraction  of  the  scripts  of 
actors  for  simple  procedures  for  data  structures  from  scenarios  of  their  Intended  use. 
Conversely,  they  aid  in  the  analysis  of  an  existing  system  by  graphically  displaying 
the  relationships  among  the  events  occuring  in  the  system  for  particular  cases  of 
behavior  Using  the  displays  available  on  our  time*sharing  system,  we  would  like  to 
automate  the  construction  and  analysis  of  event  diagrams  that  have  been  done  by 
hand  in  this  paper.  We  would  like  to  investigate  the  construction  of  an  “eclectic 
magnifying  glass"  which  provides  flexible  ways  to  specify  which  events  and 
relationships  in  the  history  of  a computation  are  to  be  be  displayed. 


This  paper  Introduces  and  describes  the  relationship  between  Event  Diagrams  and  PLASMA  for  simple 
computations  that  do  not  involve  side-effects.  Issues  of  parallelism.  Inter-process  communication,  and 
synchronization  will  be  treated  in  subsequent  papers  building  on  the  foundation  provided  by  this  paper. 
For  a mathematical  treatment  of  the  actor  model  of  computation  see  (Greif  and  Hewitt: 
SIGACT-SIGPLAN  1975)  and  (Greif:  dissertation  1975).  Issues  of  behavioral  specifications  are  treated 
in  (Greif:  dissertation  1975),  (Hewitt  and  Smith:  Towards  a Programming  Apprentice  1975),  (Yonezawa: 
Symbolic  Evaluation  as  an  Aid  to  Program  Construction). 
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SECTION  IV  — ACTOR  CONTROL  STRUCTURE 


IVI  — Introduction  to  Event  Diagrams 

From  a strictly  input-output  point  of  view  there  is  no  difference  between  iterative  and 
non-iterative  implementations  of  a module.  In  order  to  rigorously  analyze  control  structures  it  Is 
necessary  to  have  a model  of  computation  that  is  capable  of  displaying  the  Internal  structure  of 
computations. 

We  shall  use  event  diagrams  to  display  the  internal  structure  of  computations  Such  diagrams 
can  be  used  to  display  many  of  the  significant  internal  structural  relations  in  a computation.  A legend 
for  the  notation  used  in  these  diagrams  is  given  on  the  next  page. 
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Legend  for  Bvont  Diagrams 


the  'railroad  tracks'  are  used  to  Indicate  that  the 
occurrence  of  event  Ej  results  in  the  occurrence  of  the 
event  E2  and  thus  Ej  must  precede  E2  In  time.  The 
event  Ej  has  messenger  Mj  and  target  Tj  whereas  the 
event  E2  has  messenger  and  target  T2. 
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IV.2  — Actor  Transmission 


Actors  make  use  of  one  universal  communication  mechanism  called  ACTOR  TRANSMISSION 
which  consists  of  sending  one  actor  (called  the  MESSENCER  of  the  transmission)  to  another  actor 
(called  the  TARGET  of  the  transmission).  Each  actor  transmission  defines  an  EVENT  in  which  the 
MESSENCER  arrives  at  the  TARGET.  The  target  and  messenger  are  the  immediate 
PARTICIPANTS  in  the  event.  I.E.  if  E is  an  event  with  messenger  actor  M and  target  actor  T then 

(participants  E)  = {M  T) 

Actor  transmission  enables  the  knowledge  in  the  local  context  of  the  target  actor  T to  be  integrated 
with  the  inf ormation  of  the  messenger  actor  M since  the  acquaintances  of  both  the  messenger  and  target 
are  available  for  use  when  the  messenger  arrives  at  the  target.  Furthermore  this  constitutes  the  only 
information  available  at  the  instant  of  computation  defined  by  the  event? 


Event  recording  the  transmission  of  Messenger  M to  T 
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Actor  transmission  is  used  to  provide  the  necessary  communication  between  actors  to  accomplish 
the  following  kinds  of  actions: 

calling  a procedure 

obtaining  an  element  from  a data  structure 
invoking  a co-routine 
modifying  a data-structure 
returning  a value 

synchronization  of  communicating  parallel  processes 

The  actor  transmission  communication  mechanism  enforces  the  modularity  and  protection  of  actor 
systems.  It  provides  the  basis  for  constructing  actor  systems  with  explicit  modular  interfaces  such  that 
user  of  a module  (actor)  can  only  depend  of  the  behavior  of  the  actor.  The  hardware  enforces  the 
constraint  that  the  user  of  a module  cannot  depend  on  its  current  physical  representation. 


IV.2a  — Messengers 

In  order  to  have  a useful  model  of  a message-passing  system,  the  problem  of  infinite  regress  must 
be  explicitly  addressed.  The  actor  message  passing  model  provides  for  primitive  actors  to  deal  with 
this  problem.  When  a primitive  actor  receives  a request,  it  is  unnecessary  for  the  primitive  to  send  any 
further  messages  in  order  to  properly  respond  to  the  request.  In  particular  this  means  that  a primitive 
actor  must  be  able  to  obtain  some  of  the  acquaintances  of  a messenger  which  it  receives  without  having 
to  send  any  messages.  Packagers  (see  appendix)  provide  the  primitive  mechanism  needed  in  PLASMA 
for  transmitting  messengers  between  actors. 

Once  an  actor,  m,  (serving  as  messenger)  is  transmitted  to  another  actor  (serving  as  the  target),  t, 
the  computation  proceeds  by  following  the  script  of  I using  information  from  m.  For  this  to  be  of  any 
use  as  a model  of  communication,  it  must  be  that  m obeys  some  fairly  standard  conventions.  These 
provide  the  basis  for  meaningful  discourse  between  actors.  We  will  adopt  the  convention  that  all  of  the 
messengers  constructed  by  the  PLASMA  system  are  packagers?  of  the  following  form: 

(meisenger;  (agent:  a)  (envelope:  •)  (banker,  b)) 

where  a is  an  actor  representing  the  agent  responsible  for  the  computation.  • is  the  envelope  of  the 
transmission,  and  b is  the  banker  funding  the  computation.  The  explanation  of  bankers  and  agents  is 
outside  the  scope  of  this  paper  so  we  shall  say  no  more  about  them. 


2:  Readers  who  are  unfamiliar  with  the  packagers  of  PLASMA  may  wish  to  consult  the  appendix. 
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In  many  cases  the  envelope  of  a messenger  will  simply  contain  a message.  A response  to  a request 
ts  either  a REPLY  envelope  with  a reply  message  to  the  request  packaged  as 

(reply:  Ihe-meitif ) 

or  a COMPLAIN  envelope  with  a complaint  message  packaged  as 

l complain : th*-w»««ie) 

which  explains  why  the  request  could  not  be  honored. 

Often  the  envelope  of  a messenger  is  a REQUEST  which  in  addition  to  a request  message 
contains  an  actor  e to  which  a reply  to  the  request  should  be  sent.  Such  an  envelope  Is  packaged  as 
follows:  6 


(request:  th*-m*ssw  (reply-10:  c)) 

The  ACTOR  e is  closely  related  to  the  continuation  FUNCTIONS  used  by  Morris,  Wadsworth, 
Reynolds,  and  Strachey. 

An  ordinary  functional  call  to  a function  » with  arguments  «rgj, ....  through  arg^  is  Implemented 
In  PLASMA  by  passing  to  » a request  envelope  with  a message  consisting  of  the  tuple  [arg|, ....  arg^Jof 
arguments  and  a continuation  actor  to  which  the  value  of  f should  be  sent. 


IV  3 --  Request  and  Reply 

Perhaps  the  simplest  control  structure  is  the  ordinary  request  and  reply  pattern  of  activity  that  is 
implemented  in  most  programming  languages  as  a procedure  call  and  return.  None  of  the  internal 
structure  of  the  actor  being  invoked  is  shown.  Instead  the  description  articulates  only  the  input-output 
behavior  of  the  actor. 


Pag*  14 


Control  Struotaro 


Consider  the  example  of  a request  being  sent  to  an  actor  tactoria*  to  compute  its  value  for  the 
argument  tuple  [3]  and  send  the  answer  to  the  actor  C.  The  diagram  shows  the  two  events  consisting  of 
the  above  REQUEST  (i.e.  factorial  is  sent  a messenger  Mj  with  message  [3]  and  continuation  C)  and  the 
REPLY  in  which  C is  sent  a newly  created  messenger  M2  with  message  •; 


An  Evont  Diagram  for  tho  Computation  of  (factorial  3) 

The  above  event  diagram  treats  factorial  as  a "black  box"  with  none  of  the  internal  events  shown. 
Notice  that  the  computational  process  follows  the  "railroad"  tracks  from  the  first  event  to  the  second 
event.  We  will  now  proceed  to  examine  the  computation  more  closely.  This  is  an  application  of  the 
idea  of  using  an  eclectic  magnifyine  glass  to  articulate  the  description  of  a behavior  in  greater  detail 
What  is  seen  depends  on  how  factorial  is  implemented  as  well  as  the  focus  of  the  magnifying  glass. 
When  we  look  into  the  implementation  of  factorial,  we  will  see  a number  of  events  that  occur  between 
the  two  which  are  diagrammed  above. 

Note  that  the  value  • which  is  constructed  by  the  actor  factorial  is  not  an  acquaintance  of  factorial 
Instead  it  is  the  “reply"  acquaintance  of  the  messenger  M2  which  is  sent  to  the  continuation  C. 
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1V.4  — Recursion 


IV.4.a  — Scripts  for  a Non-Iterative  Factorial 


Suppose  we  have  a non-iterative  implementation  of  factorial.  A script  written  in  PLASMA  for 
such  an  implementation  is  given  below.  Readers  who  are  unfamiliar  with  the  notation  can  consult  the 
appendix  which  provides  an  informal  introduction  to  PLASMA. 


(factorial  a 
(■>[«*! 

(rutoa  n 
(*>  1 
1) 

<*>  0 1) 

(n  * (factorial  (n  - 1))))))) 


factorial  ft  defined  to  ho 
receive  a message  with  one  element  which  will  be  called  n 

;the  rules  for  n a re 
;if  it  ft  1 
;lhen  return  i 
;elte  if  fl  ft  greater  than  I then 
return  n times  factorial  of  n minus  1 
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IV.t.b  — An  Event  PlMfiw  for  lidoriil  Calling  Itself  Rwunlrrir 

We  are  interested  in  looking  more  deeply  Into  the  control  structure  of  recursive  procedures.  To 
this  end  we  take  the  above  non-iterative  implementation  of  factorial  as  a concrete  example  to  be  studied. 
When  factorial  receives  the  message  [3]  it  is  not  able  to  reply  immediately  since  it  does  not  directly  know 
what  (factorial  3}fs  Below  is  an  event  diagram  of  the  computation  that  results  from  sending  factorial  a 
messenger  Mt  with  message  [3]  and  continuation  C up  to  the  point  of  the  first  recursive  call  in  which 
factorial  is  sent  a newly  created  messenger  M2  with  message  (21  and  continuation  C’  where  C’  is  a newly 
created  actor  that  knows  about  n and  C.  The  script  of  C*  is  such  that  whenever  it  is  sent  a message  y,  It 
sends  C the  message  (3  o y). 


Control  Structure  Pl|f  jj 

Snapshot  of  Storage  at  InsUnt  when  factorial  receives  f 11 

Below  we  present  a snapshot  of  the  storage  at  the  Instant  factorial  receives  the  message  [1J.  The 
rule  for  computing  the  amount  of  storage  being  used  at  the  instant  of  any  particular  event  is  very 
simple  Merely  count  all  the  ictors  that  are  in  the  transitive  closure  of  the  acquaintances  of  the 
participants  involved  in  the  event.  Recall  that  the  participants  of  an  event  are  the  actors  immediately 
involved  (i.e.  the  target  and  messenger). 


psgs  it  Control  Structure 

IV.4.d  — Viewing  Recursion  as  a Pattern  of  Passing  Messages 

The  above  event  diagram  exhibits  the  characteristic  structure  of  a recursive  computation.  This 
pattern  Is  familiar  to  users  of  ALGOL,  LISP  1.6.  and  PL-I  and  other  programming  languages  that 
make  use  of  a pushdown  stack  to  implement  recursion.  In  such  languages  the  amount  of  stack  used  by 
the  Implementation  grows  monotonically  until  factorial  is  called  with  the  argument  1 and  then 
monotonically  decreases  as  the  stack  Is  popped. 

Below  we  give  an  event  diagram  that  displays  the  pattern  of  passing  messages  characteristic  of 
recursion  in  the  computation  of  (factorial  3).  Note  that  the  computation  proceeds  from  event  to  event 
along  the  "railroad  tracks"  in  the  diagram. 
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IV  — Characterization  of  Recursion  as  a PaMtrn  of  Pacing  Messages 

Thus  we  see  how  recursion  can  be  characterized  as  a pattern  of  passing  messages  using  event 
diagrams.  The  characteristic  feature  is  the  build  up  of  a chain  of  continuation  actors  each  one  of 
which  knows  only  about  the  next  and  which  eventually  replies  to  the  next  with  the  answer  Notice  that 
this  characterization  of  recursion  in  terms  of  relations  between  events  is  independent  of  the  syntax  of 
the  language  for  scripts  which  gives  rise  to  the  behavior.  For  example  the  same  characterization  would 
hold  for  a recursive  implementation  of  factorial  in  ALGOL.  The  semantics  of  ALGOL  can  be  defined 
using  relations  among  events  in  a manner  similar  to  the  way  in  which  the  semantics  of  PLASMA  is 
defined. 

a 

The  existence  of  the  actors  labeled  C'  and  C"  in  the  above  diagram  and  the  events  in  which  they 
are  the  target  are  difficult  to  explain  in  terms  of  the  above  PLASMA  script  for  factorial  In  order  to 
explain  the  origin  of  these  actors  and  events,  we  need  to  explain  more  of  the  underlying  implementation 
of  PLASMA. 


1V.5  — Envelope  Level  Scripts 

Thus  far  in  our  PLASMA  scripts  we  have  examined  information  communicated  in  the  messages 
of  envelopes.  At  this  point  we  would  like  to  introduce  the  envelope  level  which  allows  access  to  other 
information  in  the  messengers  of  actor  transmissions.  Every  messenger  always  contains  (among  other 
things)  an  actor  which  serves  as  the  ENVELOPE  In  turn  every  envelope  always  contains  an  actor 
which  serves  as  the  MESSACE  Additionally  REQUEST  envelopes  contain  actors  called 
CONTINUATIONS  to  which  replies  to  the  messages  should  be  sent. 

The  reason  that  it  is  useful  to  introduce  the  envelope  level  transmitters  and  receivers  into  scripts 
is  that  otherwise  much  of  the  control  structure  (pattern  of  passing  messages)  has  to  remain  implicit  in 
something  like  an  evaluator  or  a compiler.  Envelope  receivers  and  transmitters  provide  the  mechanism 
for  expressing  more  explicit  scripts  so  that  none  of  the  processing  or  allocation  of  storage  is  going  on 
behind  the  scenes. 

Envelope  receivers  and  transmitters  are  analogous  to  ordinary  receivers  and  transmitters  in  many 
respects.  They  are  intended  to  be  used  as  a notation  for  writing  scripts  in  which  all  the  computational 
events  and  actors  are  explicitly  shown.  In  this  way  the  structure  of  simple  control  structures  such  as 
iteration  and  recursion  can  be  explicitly  characterized  as  patterns  of  passing  messages. 

PLASMA  uses  the  syntactic  convention  of  using  the  number  of  shafts  on  the  transmitter  and 
receive  arrows  to  reflect  the  level  at  which  the  transmission  is  being  referenced;  one  shaft  meaning 
ordinary  message  level,  and  two  shafts  meaning  envelope  level.  Thus: 

<■  Is  an  (ordinary)  message  level-transmitter,  and 
<■■  is  a envelope-lev  el-transmitter 
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Similarly, 

■>  is  an  (ordinary)  message-level-receiver.  and 

k>  is  an  envelope-level-receiver. 

Below  we  use  this  notation  to  make  the  message-passing  underlying  the  implementation  of  PLASMA 
more  explicit. 

For  example  an  ordinary  message  receiver  which  receives  one  argument  n and  replies  with  the 
value  (n  ♦ Dwrttten  as 

(*>  [«n] 

(n  ♦ I)) 

can  be  written  at  the  envelope  level  as  follows: 

(s*>  (request:  [an]  (raply-to:  =c)) 

(C  <»  (reply:  (n  ♦ 1)))) 


IV  5a  — A More  Explicit  Script  for  the  Non-Iterative  Factorial 


The  correspondence  between  the  event  diagram  for  the  non-iterative  Implementation  of  factorial 
and  Its  script  can  be  made  more  apparent  by  using  envelope  transmitters  and  receivers  to  make  the 
underlying  implementation  explicit.  The  script  presented  below  Is  Intended  to  explicate  how  the 
implementation  of  PLASMA  actually  works. 


(factorial  a 

(n>  (request:  [an]  (reply- to: 


')) 


(ruloa  n 
(*>  1 

(c  <««  (reply.  1))) 

(■>  0 1) 

(factorial  (*» 

(request:  |(n  - 1)] 
(reply-  to: 

(ss>  (reply  ay) 


factorial  if  defined  lo  be 
.■receive  a request  to  compute  the  value  of  factorial  for 
;an  argument  tuple  whose  only  element  it  n and 
;s end  the  reply  to  the  actor  c 
;the  rule $ for  n are 
;if  il  if  1 then 
,*f end  e a reply  envelope  with  menage  1 
;el»e  if  il  if  greater  than  1 
.tend  factorial  a request 
;tvith  message  (n  - 1)  and 
;continualion  the  following  actor 
df  • reply  envelope  with  message  y if  received 


(c  <**  (reply  (y  0 n)))))))))))  ;| hen  send  c a re/sly  envelope  with  message  (y  • n) 


Notice  that  the  above  script  specifies  that  before  recursively  calling  factorial  (in  the  case  where  n*l),  a 
new  actor  is  created  as  the  reply  to:  component  of  the  envelope  sent  to  factor!*'  This  new  actor  is 
created  with  ACQUAINTANCES  n and  c and  has  the  following  SCRIPT: 
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(as>  {.reply,  *y) 

(c  <««  ( reply,  (y  * n)))) 

Operationally,  the  script  says  for  each  reply  y that  1$  received,  multiply  It  by  n and  tend  the  retailing 
product  at  a reply  to  c" 
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IV.6  — Iteration 

It  is  well  known  that  another,  more  efficient  implementation  of  factorial  uses  iterative  control 
structure.  Event  diagrams  will  be  used  as  a tool  to  Illustrate  the  behavior  of  this  more  efficient 
implementation  of  factorial.  One  idea  for  an  iterative  implementation  is  to  gradually  build  up  the 
product  while  counting  down  the  argument  -doing  one  multiply  for  each  iteration  So  we  define  an 
actor  catted  loop  which  should  be  sent  both  the  current  accumulation  (which  is  Initially  1)  and  the  current 
count  (which  is  initially  the  input  n)  on  each  iteration.  The  obvious  way  to  do  this  is  to  repeatedly  send 
loop  a sequence  of  the  form  [accumulation  count]. 


IV.6.a  — A Script  for  an  Iterative  Implementation  of  Factorial 


(factorial  = 

(s>  [«n] 

([1  n]  s> 

(loop  a 

(=>  [^accumulation  =count] 

(rutos  count 
(s>  1 

accumulation) 

(s>  0 1) 

(loop 

(accumulation  • count) 
(count  - 1))))))))) 


factorial  it  defined  to  be 
;reeei««  one  argument  and  call  it  n 
itend  a 2-tuple  with  elementt  1 and  n to 
;a  newly  created  actor  named  loop  which  behave i at  follow* 
; receive  a 2-tuple  at  the  current  accumulated  product  and  count 

it  he  rulet  for  the  count  are 
iif  it  it  1 then 
return  the  accumulation 
lelte  if  it  it  greater  than  1 
;tend  loop 

;t he  accumulation  timet  the  count 
;and  the  count  minut  one 


Notice  that  the  argument  n is  not  an  acquaintance  of  the  actor  loop  in  the  iterative 
implementation  of  factorial.  The  rule  for  calculating  the  acquaintances  from  the  script  of  an  actor 
defined  In  PLASMA  is  very  simple:  the  acquaintances  of  a newly  created  actor  are  the  actors  named  by 
the  free  identifiers  in  the  script  at  the  time  the  actor  is  created.  Instead  of  being  an  acquaintance,  the 
actor  n is  sent  to  loop  as  the  second  element  of  the  two  tuple  [1  n]. 
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IV.6.b  — An  Event  Diagram  for  Iterative  Factorial 

The  script  given  above  will  exhibit  the  behavior  diagramed  below  when  factorial  is  sent  the 
message  [3],  This  is  an  illustration  of  iteration  as  a pattern  of  passing  messages.  Note  the  repeated  use 
of  the  actor  C as  a continuation  in  the  envelopes  used  in  the  iterative  Implementation  of  factorial. 


re  ply  - to 
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^ A More  Explicit  Script  for  Iterative  Factorial 


Notice  that  the  above  implementation  of  factorial  definitely  uses  iterative  (finite-state)  control 
structure  in  the  sense  that  it  does  not  need  any  more  memory  than  that  needed  for  the  values  of  count 
and  accumulation  We  now  incorporate  envelope  transmitters  and  receivers  to  make  the  script  of  the 
iterative  implementation  of  factorial  more  explicit.  In  this  way  the  correspondence  between  the  event 
diagram  for  the  iterative  Implementation  and  its  script  becomes  more  apparent. 


(flctor)il  a {factorial  it  defined  to  bo 

(**>  (requett:  [=n]  ; receive  a requett  with  argument  tuple  [n] 

(reply-, o:  =c))  ;anrf  continaation  c 

({requett:  [1  n)  ( re  ply- to : C»  *=>  ;Send  a requett  with  argument  tuple  [1  n]  and 

continuation  c to  the  following  newly  created  actor 
(loop  - ;named  loop 

(s£>  (requett:  ^accumulation  =count]  (reply, o:  =d))  ;tuch  that  if  a requett  it  received  with 

;meuage  containing  the  accumulation  and  count 

;and  continuation  d 

<rul.«  count  icheckt  the  count 

^=>  * ;to  tee  if  it  it  1 

(d  <==  (reply  accumulation)))  ,-if  to  it  tendt  the  accumulation  at  a reply  to  d 

^ ^ ^ ;elte  if  it  it  greater  than  1 then 

(loop  <a-  ;* end  loop  a requett  with 

( requett : [(accumulation  * count)  (count  - 1)J  ;i he  appropriate  mettage 

( replyto : d))))))))))  ;and  the  continuation  d 


The  reason  that  this  is  iterative  is  that  loopalways  passes  along  the  same  continuation  actor  that  it 
receives  with  the  message.  The  only  continuation  it  needs,  and  therefore  the  only  one  that  it  holds  onto. 
Is  the  one  contained  in  the  original  envelope  that  was  sent  to  factorial.  The  loop  sends  its  answer  to  that 
continuation  directly  when  it  is  done  Thus  no  extra  storage  is  needed  going  around  the  loop 
Furthermore,  in  this  implementation  of  iteration  there  are  no  side  effects  which  change  the  behavior  of 
any  actor  If  the  user  wants,  she  can  keep  a complete  history  of  all  the  events  in  her  computation  and 
e confident  that  no  information  has  been  lost  Actor  semantics  account  for  the  iterative  behavior  of 
the  above  implementation  of  factorial  without  having  to  appeal  to  external  implicit  mechanism  such  as 
an  interpreter  or  any  kind  of  external  storage  mechanism  such  as  activation  records  All  the  behavior 
of  the  system  is  accounted  for  by  the  behavior  of  actors  when  they  are  sent  messages.  Furthermore  all 
°f  Ahc  Jt0rage  '*  accoumed  for  bY  actors  shown  in  the  event  diagrams.  Event  diagrams  show  how 
PLASMA  Is  actually  implemented  using  actors.  The  actor  model  provides  a complete  self-contained 
rigorous  theory  of  iteration  as  a pattern  of  passing  messages.  It  provides  an  explanation  for  the 
semantics  behind  the  optimization  rule  used  by  many  compilers  that  all  "tail  recursive"  self -referential 
definitions  can  be  compiled  using  special  iteration  primitives  such  as  "while"  loops,  "do"  loops,  etc. 
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IV.6.d  — Meaning  of  "Recursion" 

The  term  RECURSIVE  hai  come  to  have  at  least  three  different  meanings  in  computer  science; 

I:  Effectively  computable  as  in  "recursive  function  theory" 

2:  Self -referential  as  in  "factorial  can  be  defined  recursively  in  terms  of  itself 

S:  Non-iterative  as  in  "recursive  functions  use  up  more  push-down  stack  when  they 
call  each  other  whereas  iterative  loops  do  not" 


Both  the  iterative  and  non-iterative  definitions  for  factorial  which  we  have  presented  are 
self-referential.  However,  only  the  non-iterative  implementation  is  "recursive"  in  the  third  sense  of  the 
word. 

Using  factorial  as  a simple  example,  we  have  shown  how  the  actor  message  passing  model  can  be 
used  to  give  additional  precision  to  fundamental  concepts  in  computer  science. 
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#> 


1V.7  — Comparison  of  Recursion  and  Iteration 

Below  we  present  abstracted  versions  of  the  event  diagrams  for  the  iterative  and  non-iterative 
implementations  of  factorial  when  called  with  3 as  an  argument.  In  the  diagrams  below  the  message  is 
shown  inside  the  messenger  in  order  to  more  strongly  bring  out  the  pattern  of  message  passing. 


RECURSION 


ITERATION 


Factorial 


T 


[ 3 ] 


reply-to 


reply  - to 


Control  Structure 
SECTION  V 


EPF1C1UNCY  and  INTELLIGIBILITY 
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V I — Modular  Distribution  of  Knowledge 

Since  the  defining  characteristic  of  actors  is  that  they  send  and  receive  messages,  they  are 
relatively  unbiased  with  respect  to  assumptions  about  control  structure  and  the  distinction  between  data 
and  operators.  The  neutrality  on  the  issue  of  division  of  knowledge  between  data  structure  and 
operators  can  be  seen  in  the  various  ways  in  which  one  can  distribute  information  in  an  actor  system. 
How  one  might  choose  to  distribute  it  depends  on  one's  purposes  and  the  various  uses  to  which  the 
knowledge  can  be  put.  Often  it  is  desirable  to  represent  knowledge  redundantly  with  different  uses  of 
the  same  knowledge  appearing  in  several  guises  In  several  different  places.  The  point  is  that  the  actors 
allow  distribution  of  knowledge  in  any  way  that  is  useful. 

Early  Artificial  Intelligence  programs  were  mainly  organized  as  multi-pass  >ieuristic  programs 
consisting  of  a pass  of  information  gathering,  a pass  of  constraint  analysis,  and  a pass  of  hypothesis 
formation.  It  is  now  generally  recognized  that  multi-pass  organizations  of  this  kind  are  inflexible 
because  it  is  often  necessary  for  information  to  flow  across  these  boundaries  in  both  directions  in  a 
dialogue  at  all  stages  of  the  processing. 


V.2  — Non-halry  Control  Structure 

One  of  the  most  important  results  that  has  emerged  from  the  development  of  actor  semantics  has 
been  the  further  development  of  techniques  to  semantically  analyze  or  synthesize  control  structures  as  a 
patterns  of  passing  messages.  As  a result  of  this  work,  we  have  found  that  we  can  do  without  the 
P*r*Phernalia  of  hairy  control  structure"  (such  as  possibility  lists,  non-local  gotos,  and  assignments 
of  values  to  the  internal  variables  of  other  procedures  in  CONNIVER).  None  of  the  accouterments  of 
"hairy  control  structure"  seem  to  be  necessary  for  communication  among  the  plans  of  a high-level 
goal-oriented  formalism.  In  particular  “hairy  control  structure"  is  not  needed  to  deal  effectively  and 
efficiently  with  anomalies  and  complaints  encountered  in  the  course  of  attempting  to  mechanize 
problem  solving  in  such  a formalism.  The  conventions  of  ordinary  message-passing  seem  to  provide  a 
structured,  more  intuitive,  foundation  for  constructing  the  communication  systems  needed  for 
expert  problem-solving  modules  to  cooperate  effectively. 

We  have  discovered  a syntactic  transformation  by  which  it  is  possible  to  convert  a program  which 
UJfs  hairy  control  structure  into  an  equivalent  program  that  uses  ordinary  message  passing.  The  first 
step  of  the  transformation  is  to  convert  each  ordinary  message  receiver  =>  into  the  form  ==>  and  each 
ordinary  message  transmitter  ■>  into  the  form  =*>  using  the  techniques  used  in  the  examples  above. 
The  next  step  then  simply  to  convert  each  envelope  level  receiver  sa>  into  s>  and  each  each  envelope 
level  transmitter  «*>  into  ■>.  The  result  is  a program  which  make  no  use  of  hairy  control  structure. 
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However,  it  is  not  recommended  that  the  above  method  be  used  to  convert  programs  that  use 
hairy  control  structure.  The  best  way  to  achieve  an  efficient  modular  implementation  of  a problem 
solver  is  to  reason  directly  in  terms  of  the  behavior  required  to  solve  the  problem.  It  is  highly 
undesirable  to  take  a program  that  is  difficult  to  understand  because  of  the  use  of  hairy  control 
structure  and  "improve"  it  by  eliminating  the  hairy  control  structure  by  a local  syntactic  transformation 
such  as  the  one  discussed  above.  In  general  such  local  transformations  make  badly  structured 
programs  worse  instead  of  better. 

We  will  present  two  examples  of  problems  where  hairy  control  structure  was  originally  used  to 
implement  a difficult  problem.  As  the  problem  to  be  solved  has  become  better  understood,  more 
intelligible  solutions  which  do  not  involve  hairy  control  structure  have  been  developed. 

V.3  — Gaining  Efficiency  thru  Progressive  Refinement 

Efficient  implementations  of  systems  are  usually  most  easily  arrived  at  by  beginning  with  a 
high-level  goal-oriented  plan  and  then  progressively  refining  using  specific  domain-dependent 
knowledge.  For  example  a simple  recursive  implementation  for  computing  bas*#*P®n#,rt  is  given  below: 

(integer-exponentiation  = 

(s>  [sbase  ^exponent] 

(rules  exponent 

\ (2>  0 

1) 

(else 

(base  * (integer-exponentiation  base  (exponent  - 1))))))) 

In  the  above  example  we  have  made  use  of  an  expression  of  the  form 

(«(*«  body) 

as  a convenient  mnemonic  abbreviation  for 

(s>  ? body) 

making  use  of  the  fact  that  the  pattern  f will  match  anything. 

The  above  plan  is  too  inefficient  to  use  to  calculate  large  exponents.  However,  we  do  not  Intend 
to  use  it  for  this  purpose!  Instead  of  executing  the  plan,  we  propose  to  refine  it  to  make  It  more 
efficient.  These  refinements  have  been  accomplished  by  using  a great  deal  of  mathematical  and 
i problem  solving  knowledge. 

The  efficiency  of  the  exponentiation  routine  can  be  improved  by  transforming  it  into  an  Iterative 
form  using  the  f act  that  integer  multiplication  is  associative: 
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(integer-exponentiation  = 

(*>  [=ba*e  sexponent] 

([exponent  1]  => 

(till-exponent-sero  s 
(— > [so  ^accumulation] 

(rules  e 
(a>  0 

accumulation) 

(a/sa 

(till-exponent-zero 
(e-  1) 

(accumulation  * base))))))))) 

However,  the  above  procedure  is  still  not  very  efficient. 

Notice  that  if  exponent  is  an  even  integer  then 

bas.exponent  , (b„,  , bn#)(exponent  / 2) 

The  above  arithmetical  fact  can  be  used  as  the  basis  for  making  a faster  exponentiation  routine; 

(faat-oxponontiation  a 
(*>  [abase  sexponent] 

([base  exponent  1]  => 

(till-exponent-zero  ■ 

(*>  [»b  se  s accumulation] 

(rules  e 
(i>  0 

accumulation) 

(*>  (avan) 

(till-exponent-zero 

(b*b) 

(e/2) 

accumulation)) 

(also 

(till-exponent-zero 

b 

(e-  1) 

(b  e accumulation))))))))) 

This  last  refinement  is  probably  fast  enough  for  most  practical  purposes.  However,  John  Reynolds  has 
pointed  out  that  the  above  program  Is  still  inefficient  In  two  ways: 
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After  it  is  determined  that  the  exponent  is  odd,  when  the  loop  is  continued  it  is 
unnecessary  to  test  that  (exponent  - l)ls  even. 


After  it  is  determined  that  the  exponent  is  non-zero  but  even,  when  the  loop  is  continued 
it  is  unnecessary  to  test  that  (exponent  / 2)is  non-zero. 

Reynolds  showed  how  these  inefficiencies  could  be  removed  by  the  use  of  assignment  statements  and 
got  os. 

The  double  testing  is  easily  eliminated  in  PLASMA  by  simply  defining  two  auxiliary  actors 
which  handle  positive  and  even  exponents  as  special  cases.  This  example  demonstrates  how  the 
underlying  strategies  of  optimizations  can  be  captured  by  reasoning  in  terms  of  message-passing. 

(taster-exponentiation  * 

(*>  [>bm  =exponent] 

(let 

(pooitivo-oxponont  = 

(s>  [=b  so  = accumulation] 

(ruloa  o 
(*>  {even) 

(positive-exponent 

(bob) 

(o/2) 

accumulation)) 

(else 

(even-exponent 

b 

(o-l) 

(b  * accumulation)))))) 

(even-exponent  s 

(*>  [«b  se  x accumulation] 

(rules  e 
(i>  0 

accumulation) 

(else 

(positive-exponent 

(bob) 

(o/2) 

accumulation))))) 

then 

(rules  exponent 
(a>  0 
1) 

(also 

(positive-exponent  baso  exponent  1)))))) 
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The  point  of  this  example  is  that  viewing  control  structure  as  a pattern  of  passing  messages  can 
be  used  to  motivate  optimizations  that  improve  efficiency.  A good  programming  methodology  involves 
writing  high-level  goal-oriented  plans  to  specify  a task  followed  by  progressively  refining  these  plans  to 
obtain  efficient  implementations.  To  support  a programming  methodology  based  on  progressive 
refinement,  it  is  necessary  to  have  a unified  coherent  formalism  which  can  encompass  the  necessary 
range  of  plans.  The  formalism  needs  to  be  sufficiently  powerful  to  represent  any  potential  optimization 
so  that  the  complexity  and  efficiency  of  the  optimization  can  be  calculated 


V.4  --  Generators 

In  knowledge  based  systems,  it  is  unreasonable  to  store  alt  the  implications  of  the  knowledge 
available  at  a given  time.  Explicitly  storing  the  answers  to  all  possible  questions  instead  of 
incrementally  generating  them  as  they  are  needed  is  not  only  extremely  inefficient  since  most  of  them 
may  never  be  needed,  but  may  in  fact  be  impossible.  For  example  expanding  out  all  the  possible  games 
of  chess  before  making  the  first  move  is  clearly  infeasible  The  therefore  it  must  be  possible  to 
incrementally  generate  implications  as  needed  in  order  to  answer  questions. 


In  order  to  deal  with  this  problem  Newell,  Shaw,  Simon  introduced  a form  of  generators  Into 
their  Information  Processing  Language.  Since  that  time,  the  concept  has  undergone  considerable 
further  development.  In  terms  of  actors  the  idea  is  to  construct  a sequence  t which  behaves  like  a 
sequence  of  the  possible  answers  to  some  question.  The  trick  Is  that  s does  not  physically  contain  all  the 
answers  but  rather  generates  them  incrementally  as  needed.  To  make  this  discussion  more  concrete  we 
present  a simple  problem  that  illustrates  how  generators  can  be  conveniently  implemented  in  PLASMA. 


We  will  assume  that  we  have  some  actors  called  trees  such  that  each  tree  is  either  of  the  form 
(terminal:  T)where  T Is  the  terminal  symbol,  or  of  the  form  (non-iermina/;  L R)where  L and  R are  left  and 
right  sub-trees. 


For  example  the  tree 


( mom-terminal : 

( mon-terminal : (terminal:  A)  (terminal:  B)) 
(terminal:  C)> 


has  the  following  fringe  (sequence  of  terminals  In  left  to  right  order)  [A  B C) 
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as  does  the  following  tree 


(nan-terminal: 

(terminal:  A) 

( non-terminal : ( terminal : B)  (terminal:  C)» 


whereas  the  following  tree 


( non-terminal : 

(terminal:  C) 

(non- terminal:  (terminal:  A)  (terminal:  B)|) 


has  [C  A B)as  its  f ringe. 


The  problem  is  to  define  the  actor  fringe  so  that  for  any  tree  T,  (fringe  T)behaves  like  a sequence 
of  the  terminal  elements  of  T.  There  are  two  important  properties  that  characterize  the  behavior  of 
(ring*.  First,  fringe  of  a terminal  node  must  behave  like  a sequence  with  one  element 


(fringe  (terminal:  T))  " [TJ 

The  symbol  • is  used  to  denote  behavioral  equivalence  of  actors.  Second,  fringe  of  a non-terminal  node 
must  behave  like  the  sequence  produced  by  concatenating  the  fringe  of  the  left  sub-node  and  the  fringe 
of  the  right  subnode 

(fringe  (nee -terminal:  L R))  ~ [{(fringe  L)  {(fringe  R)] 

The  above  specification  makes  use  of  the  unpack  operator  { of  PLASMA  which  is  explained  in  the 
appendix. 
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V4a  — A High-Level  Implementation 

From  the  above  behavioral  specifications  we  can  immediately  derive  the  following 
Implementation  of  fringe: 


(fringe  a 

(»>  [atha-traa] 

(rules  tha-traa 

(a>  ( terminal : «T) 

(T]) 

(*>  [non-terminal:  =L  =R) 

[! (fringe  L)  ! (fringe  R)])))) 


Ithe  behavior  of  fringe  it  defined  to  bo 
whenever  it  rereivet  a tree 
Ithe  rule t for  the  tree  are 
;if  it  a terminal  T 
;l hen  the  fringe  it  a tequence  whole  only  element  it  T 
;elte  the  tree  mutt  be  a non-terminal 
;and  the  fringe  of  the  tree  it 
;l he  fringe  of  in  left  tub-tree  concatenated  with 
;lhe  fringe  of  ilf  right  tub-tree 


Unfortunately,  the  above  implementation  Is  not  incremental  because  it  immediately  looks  at  all  the 
nodes  of  the  tree  and  thus  is  exponentially  inefficient.  The  above  definition  of  fringe  is  still  very  much 
» specification  of  what  fringe  Is  supposed  to  do  as  opposed  to  a detailed  specification  of  how  to 
efficiently  accomplish  the  task  This  lack  of  concern  with  the  details  of  implementation  is  the  chief 
advantage  (and  at  the  same  time  the  chief  disadvantage)  of  high-level  implementations 


V.4b  — An  Incremental  Implementation 

Incremental  generation  amounts  to  adopting  a ’wait  and  see*  approach  as  to  whether  the  rest  of 
the  elements  will  be  needed.  The  above  Implementation  of  fringe  can  be  refined  to  be  incremental  by 
use  of  the  delay  operator.  Readers  who  are  not  familiar  with  the  delay  operator  of  PLASMA  should 
consult  the  appendix. 


(fringe  s 

(■>  [■the-tree] 

(rules  the-tree 

(»  ( terminal : *T) 

[T]> 

(s>  ( non-terminal : =L  =R) 


It  he  behavior  of  fringe  it  defined  to  be 
whenever  it  receivoi  a tree 
;l he  rulet  for  the  tree  are 
;if  it  a terminal  T 
;lhen  the  fringe  it  a tequence  whole  only  element  it  T 
lelte  the  tree  mutt  he  a non-terminal 


[tldelay  (fringe  L))  Udelay  (fringe  R))])))) 


land  the  fringe  of  the  t.'M  it 
llhe  fringe  of  it*  left  tub-tree  concatenated  with 
Ithe  fringe  of  ilt  right  tub-tree 


The  "wait  and  see"  approach  is  not  always  the  most  efficient  implementation  for  every  problem. 
In  particular  often  there  is  a space-time  trade-off  In  the  use  of  the  delay  operator  In  many  cases  it  Is 
more  efficient  to  simply  compute  an  expression  E immediately  than  to  wait  by  the  use  of  ( delay  L)slnce 
the  latter  can  cause  the  retention  of  extra  unnecessary  storage  For  example  consider  the  following 
definition: 


Pag*  34 


Control  Structure 


(to 

(■>  [n  «h] 

(rulM  i 

(■>  « 3) 

0) 

(else 

h»» 

Notice  that  the  expression  (f  2 HUGE)immed lately  evaluates  to  0 whereas  tne  expression 
(delay  (t  2 HUGE))is  an  arbitrarily  large  amount  of  storage  which  will  eventually  evaluate  to  0.  The 
reader  might  consider  how  the  efficiency  of  the  implementation  of  the  delay  operator  can  be  improved 
using  partial  evaluation. 

An  additional  complexity  is  that  PLASMA  uses  incremental  sequences  to  implement  pattern 
directed  retrieval  from  a data  base.  This  data  base  must  have  side-effects  because  it  is  used  to 
implement  communicating  parallel  processes  [Greif  and  Hewitt  1975].  In  this  application  the  "do  it  now* 
and  ’wait  and  see*  implementations  can  result  in  different  sequences  of  values’  In  order  to  make 
interprocess  communication  work  properly,  careful  control  must  be  maintained  over  when  delays  are 
introduced  into  PLASMA  scripts.  This  issue  arises  in  the  implementation  of  shared  resources  whos 
integrity  must  be  protected  as  they  are  used  by  communicating  parallel  processes.  For  this  reason 
PLASMA  has  been  not  been  designed  to  use  the  delay  rule  for  evaluation  as  the  default  evaluation 
mechanism  as  has  been  proposed  for  lambda  calculus  languages  by  Church,  Cadiou,  Vuiltemin, 
Wadsworth,  Henderson  and  Morris,  and  Friedman  and  Wise.  Carried  to  its  logical  extreme  the 
ultimate  form  of  the  uniform  delay  rule  is  to  never  compute  the  value  of  any  expression  unless  the 
value  is  needed  for  output  to  the  external  environment! 
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SECTION  VI  — The  LA  MB  DA  CALCULUS  of  CHURCH 

As  we  have  explicitly  acknowledged  in  our  previous  papers,  the  development  of  PLASMA  and 
the  actor  model  of  computation  has  been  strongly  influenced  by  the  lambda  calculus  and  by  the  work  of 
numerous  researchers  who  have  studied  it.  The  lambda  calculus  of  Church  is  a suitable  formalism  for 
studying  the  behavior  of  effectively  computable  functions 

In  our  research  we  have  attempted  to  constructively  build  on  this  previous  work  by  d eveloplng  a 
problem  solving  formalism  and  semantic  model  for  actors  such  as  cells,  serializers,  and  funnels  which  do 
not  behave  like  mathematical  functions.  In  the  sections  below  we  investigate  the  different  ways  that 
previous  researchers  have  used  the  lambda  calculus  as  a formalism  for  studying  the  semantics  of 
procedures 

The  actor  model  of  computation  is  based  on  incidental  and  causal  relations  among  events  where 
each  event  is  defined  by  the  act  of  sending  one  actor  to  another.  Thus  it  is  incorrect  to  speak  of  an 
"actors  interpreter"  because  a semantic  model  does  not  specify  a language  which  can  be  executed.  The 
relationship  between  actors  and  PLASMA  is  analogous  to  the  relationship  between  mathematical 
functions  and  the  lambda  calculus  Although  there  is  a well  developed  mathematical  theory  of 
functions  as  sets  of  ordered  pairs,  there  is  no  such  thing  as  a "functions  interpreter"  The  lambda 
calculus  is  just  one  of  many  possible  languages  which  can  be  used  to  define  the  behavior  of 
mathematical  functions.  Similarly,  PLASMA  is  just  one  of  many  possible  languages  that  can  be  used  to 
define  the  behavior  of  actors. 

In  seme  useless  sense  all  programming  languages  are  equivalent.  It  is  possible  to  simulate  the 
behavior  of  any  programming  language  using  any  other  programming  language  in  common  use. 
Naively  it  might  be  thought  that  ALGOL  is  "more  powerful"  than  FORTRAN  because  ALGOL  has 
recursion  and  FORTRAN  doesn’t  However,  there  is  a programming  style  in  FORTRAN  which 
enables  recursive  programs  to  be  written  in  FORTRAN  corresponding  very  closely  to  the  way  in  which 
the  programs  would  be  written  in  ALGOL.  The  simu'ation  involves  allocating  a large  array  to  hold 
the  temporary  values  needed  in  recursion.  Similarly  it  is  possible  to  simulrte  the  behavior  of  PLASMA 
using  a lambda  calculus  interpreter.  The  table  below  gives  a simulation  method  for  important 
behaviors  of  actors: 


BEHAVIOR  PLASMA  LAMBDA  CALCULUS 

PRIMITIVE  SIMULATION  TECHNIQUE 


mutual-reference  labels 

side-effects  cell 

synchronization  serializer 

parallelism  funnel 


V operator 

"global  state"  of  memory 
"global  oracle" 

"global  slate"  of  program  counters 


All  of  the  above  simulation  techniques  work  by  systematically  adding  extra  arguments  to  lambda 
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expressions.  To  simulate  cells  [Seott-Strachey]  an  extra  argument  is  added  to  every  lambda  expression 
which  is  to  be  bound  to  a lambda  expression  which  contains  the  "current  contents’  of  alt  the  cells  on  all 
the  machines  of  the  system  An  assignment  of  new  contents  to  a cell  is  simulated  by  constructing  a new 
lambda  expression  which  simulates  the  "next  global  state"  of  all  the  cells  on  the  machines  Similarly  to 
simulate  synchronization  an  extra  argument  is  added  to  every  lambda  expression  which  is  to  be  bound 
to  a lambda  expression  which  simulates  the  "next"  instruction  to  be  executed  on  one  of  the  machines 
executing  in  parallel.  Thus  the  lambda  calculus  can  be  used  to  simulate  the  behavior  of  an  actor  system 
running  on  a network  of  machines  executing  in  parallel.  The  lambda  calculus  simulation  approach 
attempts  to  model  all  behavior  by  reduction  to  lambda  abstraction  and  application  This  raises  an 
important  question: 

For  what  purposes  is  lambda  calculus  simulation  a useful  model  of  computation? 

The  answer  to  this  question  is  currently  under  Investigation  by  many  researchers.  We  suspect  that  it 
will  be  several  more  years  before  researchers  have  reached  a consensus  of  opinion  on  the  question. 
However,  we  can  make  a few  preliminary  remarks  that  bear  on  what  the  ultimate  answer  might  be. 

Simulation  using  lambda  expressions  does  not  correspond  very  ciosely  to  the  mechanisms  that 
tfe— i actually  used  to  implement  communicating  parallel  processes  on  a network  of  machines 
executing  in  parallel.  Networks  of  machines  will  soon  become  very  common  because  of  the  rapidly 
decreasing  cost  of  processors  and  rapid  development  of  technologies  to  inexpensively  provide 
high-bandwidth  connections  between  machines. 

PLASMA  attempts  to  provide  modular  primitives  which  are  intended  to  be  used  to  implement 
abstractions  that  manifest  useful  problem  solving  behaviors  such  as  communicating  parallel  processes 
Within  the  actor  model  of  computation,  the  behaviors  of  primitives  such  as  cells,  serializers,  and  funnels 
are  axiomatized  using  incidental  and  causal  relations  among  events.  The  actor  model  is  intended  to 
serve  as  the  semantic  foundation  for  a Programming  Apprentice  that  supports  an  evolutionary 
behavioral  programming  methodology.  !n  order  for  a Programming  Apprentice  to  communicate 
effectively  with  the  programmers  building  a system,  it  needs  a semantic  model  which  closely  corresponds 
to  the  way  in  which  programmers  think  about  their  computations  The  actor  message-passing  model 
corresponds  closely  to  the  mechanisms  that  are  actually  used  to  implement  communicating  parallel 
processes  on  networks  of  machines. 
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SECTION  VII  — FUTURE  WORK 


Vll.i  — Applications 

The  PLASMA  system  described  In  this  paper  Is  currently  being  Implemented  at  the  MIT 
Artificial  Intelligence  Laboratory.  In  the  spring  of  1975,  PLASMA  was  defined  meta -circularly  In  terms 
of  Itself  and  then  translated  by  hand  into  LISP  using  making  use  of  LISP  macros  written  by  Russ 
Atkinson  that  make  LISP  resemble  a subset  of  PLASMA  In  the  fall  semester  of  1975  the  translation 
was  completed  and  brought  into  an  efficient  running  state  by  Howie  Shrobe  However,  more  work  Is 
needed  before  it  will  be  usable  for  writing  large  systems  This  implementation  [which  has  modularity 
and  good  human  engineering  as  its  chief  design  goals]  is  still  under  development  It  is  based  on  the 
actor  transmission  communication  mechanism  using  primitive  actors  coded  In  LISP  The  development 
of  the  actor  metaphor  will  continue  In  the  next  year  to  gain  some  experience  In  using  It  for  the 
following  kinds  of  applications: 

to  implement  a distributed  symbolic  evaluator  for  a Programming  Apprentice  [Hewitt 
and  Smith  1975,  Rich  and  Shrobe  1975,  Yonezawa  1975] 


to  Implement  other  procedural  knowledge-based  systems  such  as  a stereotype-based  visual 
perception  system  [McLennan  1975] 


as  a formalism  for  defining  message  passing  systems  to  try  out  Ideas  for  the  modular 
distribution  of  knowledge  for  a society  of  communicating  experts 


to  experiment  with  various  scheduling  and  synchronization  policies  using  serializers 
[Atkinson  and  Hewitt  1976] 


as  a basis  for  a flexible  actor-based  animation  language  [Kahn  1976] 
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VIM*  — Incremental  Perpetual  Development 

The  development  of  any  large  system  (viewed  as  a society)  having  a long  useful  life  must  be 
viewed  as  an  Incremental  and  evolutionary  process  Development  begins  with  specifications,  plans, 
domain  dependent  knowledge,  and  scenarios  for  a large  task  Attempts  to  use  this  information  to  create 
an  implementation  have  the  effect  of  causing  revisions  additions,  deletions,  modifications, 
specializations,  generalizations,  etc  At  all  times  in  the  perpetual  development  of  the  system  the 
programmers  are  conf  ronted  with 

I:  A progression  of  more  refined  plans  [programs.  Implementations,  etc] 
which  partially  accomplish  some  of  the  tasks  specified. 

2:  Partial  specifications  [contracts,  intentions,  constraints,  etc.]  for  some  of 
the  subtasks  which  are  to  be  accomplished. 

3:  Partial  justifications  [proofs,  demonstrations,  analysis  of  dependencies] 
regarding  how  some  of  the  plans  satisfy  some  of  their  specifications. 

4:  Partial  descriptions  of  some  of  the  background  knowledge 

[mathematical  facts,  physical  laws,  questions  of  interactive  users,  government 
regulations,  etc.]  of  the  environment  in  which  the  system  will  operate. 

3:  A collection  of  scenarios  [at  various  articulations  of  detail] 

demonstrating  how  the  system  is  supposed  to  work  in  concrete  instances. 

The  success  of  an  evolutionary  behavioral  modeling  methodology  is  highly  dependent  on  the 
development  of  competent  Programmine  Apprentices  [Hewitt  and  Smith  1975,  Rich  and  Shrobe 
1976,  Yonezawa  1976]  that  help  keep  the  above  potentially  disparate  descriptions  of  a system 
coherently  organized.  The  primary  benefit  of  maintaining  this  coherence  is  not  to  prove  once  and  for 
all  that  the  implementation  is  CORRECT  in  any  absolute  sense.  Changes  in  the  environment  external 
to  the  system  will  require  that  the  system  must  either  adapt  its  behavior  to  the  changed  circumstances  or 
be  supplanted  Rather  the  chief  benefit  of  demonstrating  the  coherence  of  multiple  descriptions  of 
a system  Is  to  make  the  dependencies  amone  the  parts  explicit  so  that  the  system  can  be  readily 
adapted  to  the  perpetually  changing  external  environment.  Already  for  many  systems  considerably 
more  money  is  spent  on  modification  and  enhancement  than  on  initial  design  and  implementation. 
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V>!2  — The  Actor  IProbiem-Solving  Metaphor 

The  actor  metaphor  for  problem  solving  is  a large  human  scientific  society  each  actor  li  a 
scientist  Each  has  her  ohm  duties  specialties,  and  contracts  Control  is  decentralized  among  the  actors. 
Commumca?,on  is  highly  stylized  arid  formal  using  messages  that  are  sent  to  individual  actors 

Problem  solving  proceeds  by  »he  attempts  of  experts  to  guess,  or  to  conjecture  a plan  for  a 
solution  followed  by  a'tempts  to  criticize  the  usually  somewhat  faulty  initial  plan  Plans  for  action  are 
put  forward  for  trial,  to  be  eliminated  or  modified  if  not  germane  to  the  problem  at  hand  Tentative 
acceptance  of  a proposed  plan  must  be  combined  with  an  ability  to  revise  it  if  It  is  demonstrated  to  be 
Infeasible  We  make  it  our  task  to  construct  expert  problem  solving  modules  to  live  in  a world 
characterized  by  incomplete  knowledge,  to  adjust  themselves  to  it  as  well  as  they  can,  to  take  advantage 
of  the  opportunities  they  can  find  in  it,  and  to  solve  the  problem,  if  possible  (they  need  not  assume  that 
it  lx),  with  the  help  of  the  knowledge  available  If  this  is  the  task,  then  there  is  no  more  rational 
procedure  than  l-he  method  of  planning,  refining,  and  criticizing  of  proposing  new  plans, 
progressively  refining  these  plans  to  incorporate  knowledge  relevant  to  their  execution,  criticizing  these 
refinements  to  expose  their  deficiencies,  and  of  tentatively  following  them  If  they  survive 

Newell  (1962)  points  out  two  potential  difficulties  which  must  be  dealt  with  by  systems  which 
adopt  the  actor  problem  solving  methodology  First,  the  messages  (carried  by  the  messengers)  must 
sometimes  contain  strategies,  not  |ust  facts  They  must  be  in  the  form  of  partial  information  that  can 
De  combined  wi'h  other  information  available  to  the  target  actor  A good  formal  language  must  be 
developed  for  this  kind  of  communication  The  second  potential  difficulty  is  that  a society  operating  In 
this  fashion  must  not  become  a bureaucracy  bogged  down  in  sending  messages  back  and  forth  without 
making  any  progress  We  propose  to  rely  on  the  critical  nature  of  actors  which  are  delegated  subtasks 
to  help  control  aimless  thrashing 

We  would  like  to  emphasize  that  In  the  current  state  of  the  art  only  a small  part  of  this 
metaphor  can  be  realized  in  practice.  At  this  point  in  time  the  metaphor  serves  mainly  to  provide 
suggestions  of  directions  in  which  to  work  Perhaps  in  the  very  far  future  it  will  be  possible  to 
construct  computer  systems  which  have  a significant  fraction  of  the  expertise  and  communication  ability 
of  a small  scientific  subfield 
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PLASMA  has  beer,  designed  to  provide  the  basis  for  the  Implementation  of  a Programming 
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Apprentice  for  expert  programmers.  The  behavioral  programming  methodology  which  PLASMA  Is 
Intended  to  facilitate  owes  a tremendous  Intellectual  debt  to  the  concepts  in  SIMULA  [Birtwistle  et  al. 
1973,  Palme  19731  We  are  indebted  to  Alan  Kay  for  calling  our  attention  to  these  virtues  of  SIMULA. 

The  current  Implementation  of  PLASMA  was  designed  by  Carl  Hewitt  and  has  been 
'fnplemented  in  LISP  over  the  last  year  by  a team  of  people  whose  principal  members  were  Russ 
Atkinson,  Tom  Downey,  Carl  Hewitt,  Marilyn  Mclennan,  and  Howie  Shrobe  The  implementation  has 
been  accomplished  using  a set  of  LISP  macros  implemented  by  Russ  Atkinson  that  make  LISP  Into  a 
very  limited  subset  of  PLASMA  Howie  Shrobe  put  the  system  together  in  the  fall  semester  of  1975. 
This  spring  Marilyn  McLennan  has  brought  the  system  to  a usable  state.  Tom  Downey  and  Jerry 
Morrison  have  Implemented  a modular  foimat  printer  for  PLASMA  programs  Carl  Hewitt  and  Russ 
Atkinson  have  designed  modular  primitives  for  the  implementation  of  parallelism  and  synchronization 
in  PLASMA 
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SECTIOW  X — APPENDIX:  Introduction  to  PLASMA 


X.l  --  Sequences  and  Collections 

We  will  begin  by  presenting  some  very  simple  PLASMA  scripts  and  gradually  work  our  way  up 
to  more  complicated  examples. 

Meta-syntactic  variables  will  be  underlined. 

We  note  initially  that  [Aj  A2  ...  A^Jmeans  an  ordered  sequence  of  the  actors  Ajthrough 
Afjwhereas  (Aj  Aj  ...  [means  a unordered  collection  of  the  actors  Ajthrough  A^Thus  [3  ’b]is  not 
equivalent  to  [*b  3Jalthough  {3  ’b}is  equivalent  to  {*b  3}.AIso  collections  behave  differently  from 
mathematical  sets  in  that  (3  ’b  3}is  not  equivalent  to  {3  ’bjbut  is  equivalent  to  {3  3 ’b). 

Thus  PLASMA  has  syntactic  delimiters  which  are  used  consistently  for  the  following  different 
purposes: 


[...]  delimits  an  ordered  sequence  of  elements 
(...)  delimits  an  unordered  collection  of  elements 
(...)  delimits  an  expression  in  PLASMA 


X.2  — Transmitters 

A simple  syntax  for  sending  an  actor  M(called  the  message)  to  an  actor  T(cal1ed  the  target)  is: 

(TO  M) 

or  the  following,  which  is  entirely  equivalent^ 


(M  =>  T) 

Thus, 

([’this  'is  'a  'simple  ’sentence]  »>  parser) 

will  send  a sequence  of  the  five  symbols  ’this,  'is,  'a,  'simple,  and  'santanca  to  the  actor  denoted  by 

parser. 


3:  The  reason  for  having  two  different  syntactic  forms  for  the  transmission  of  a message  is  that  often 
it  is  more  readable  to  have  the  expression  for  the  message  before  the  expression  for  the  target  or  vice 
versa.  The  difference  is  particularly  noticeable  when  one  is  much  smaller  than  the  other. 
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Since  it  is  very  common  to  want  to  send  a sequence  of  arguments  to  an  actor,  a simple  syntactic 
form  is  needed  for  this  purpose.  For  example  the  notation  used  above  would  require  us  to  write 
(♦  <■  [x  y z])in  order  to  compute  the  sum  of  x.  y.  and  a.  whereas  we  would  prefer  use  the  syntax 
<♦  * y x) 

In  PLASMA,  as  in  LISP,  an  expression  of  the  form  (Ej  Ej  ...  E^kirdinarily  denotes  an  ordinary 
procedure  call  with  procedure  Ej  and  arguments  E^, ....  and  §„.  Since  PLASMA  also  uses  parentheses  as 
the  delimiters  of  special  syntactic  forms,  it  needs  to  have  some  mechanism  to  distinguish  special  syntactic 
forms  such  as  (♦  <=  [3  4))f rom  ordinary  procedure  calls  so  that  <=  is  not  taken  to  be  the  second 
argument  of  f.  PLASMA  uses  RESERVED  SYMBOLS  in  parenthesized  expressions  for  this  purpose 
For  example  both  =>and  <«are  reserved  symbols  Transmitters  using  the  reserved  symbols  =>and  <*are 
read  as  forms  of  the  verb  "SEND"  For  example  (f  <»  [1  3])would  be  read  as  "<  is  sent  the  sequence  1 
3",  or  "a  sequence  of  1 and  3 is  sent  to  f. 

For  example 


(factorial  3)  is  equivalent  to 

(generate)  is  equivalent  to 


(factorial  <=  [3]) 
([]  =>  ganarata) 


Note  that  when  either  of  the  transmitter  arrows  <=or  *>is  written 
out  explicitly  in  a special  syntactic  form,  there  is  always  one 
expression  before  the  arrow  and  one  after  it. 

Also  note  that  arithmetic  can  be  expressed  in  infix  notation  as 
well  as  prefix  notation.  Arithmetic  expressions  are  implemented 
in  PLASMA  by  making  arithmetic  symbols  such  as  ♦ and  * 
reserved  symbols  so  that  special  modules  associated  with  these 
symbols  can  process  the  expression  in  which  they  occur  when  the 
script  is  reduced. 

The  syntactic  forms 


(target  <«  menage)  and  (menage  ->  target) 

are  designed  to  direct  the  eye  of  the  reader  along  the  normal  flow  of  control  of  the  message  to  the 
target.  The  transmitters  of  PLASMA  are  a generalization  of  the  functional  applications  in  the  lambda 
calculus  of  Church  which  were  defined  in  terms  of  substitution  semantics.  The  semantics  of 
transmitters  are  behaviorally  defined  in  terms  of  events  in  the  actor  message-passing  model 
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X.3  — Pattern  Matching 

Pattern  matching  is  used  in  PLASMA  to  recognize  actors  which  satisfy  a simple  description  and 
to  bind  the  answers  to  simple  requests.  The  process  Is  meant  to  be  quite  intuitive.  For  example  The 
prefix  ■ in  front  of  an  identifier  name  in  a pattern  can  be  used  to  bind  the  identifier  to  the 
corresponding  object  being  matched  For  example  typing 

( match  [=x  sy]  la  [3  4]) 


can  be  used  to  bind  x to  3 and  y to  4 


X.4  — Receivers 


Corresponding  to  the  syntax  for  sending  messages  is  a syntax  for  their  reception.  A PLASMA 
message-receiver  has  the  following  syntax: 

(s>  pattern 
body) 

where  the  reserved  symbol  s>is  read  as  ’RECEIVE"  Note  the  use  of  the  three  horizontal  bars  for  the 
shaft  a receive  arrow  as  opposed  to  the  use  of  two  horizontal  bars  for  a transmitter  arrow  If  an  actor 
with  the  above  definition  is  sent  a message  which  matches  pattarnthen  bodywill  be  evaluated  in  the 
environment  resulting  from  the  pattern  match.  For  example  the  PLASMA  expression 

US  7]  x>  {tend  the  tuple  whose  firit  element  it  S and  second  element  7 

(*>  l**  *y]  • receiver  which  namet  the  firtt  element  ef  the  sequence  received  n and  the  second  y 

l*  * /)))  ;and  replies  with  the  sum  of  x mnd  y 

evaluates  to  12. 

For  the  sake  of  exposition  we  will  call  the  actor  that  (s>  pattern  body)creates  a receiver  The 
behavior  of  the  receiver  is  roughly  as  follows:  when  the  receiver  is  sent  a message,  it  matches  it  against 
the  pattern.  A PATTERN  is  an  actor  which  decides  whether  it  will  match  another  actor  called  an 
object  - the  process  is  asymmetric.  If  the  match  is  unsuccessful,  then  the  receiver  complains  that  the 
message  is  not  acceptable.  If  the  match  is  successful,  the  pattern  creates  a new  environment  (which 
contains  the  bindings  that  resulted  from  the  matching  process).  The  receiver  then  sends  the  body  an 
eval  message  that  contains  the  new  environment. 

The  syntactic  form  for  receivers 


(s>  pritarn  body) 


I 


1 
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Is  designed  to  direct  the  eye  of  the  reader  along  the  normal  flow  of  control  with  the  message  through 
the  pattern  into  the  body.  The  receivers  of  PLASMA  are  a generalization  of  the  lambda  expressions 
which  were  defined  by  Church  in  terms  of  substitution  semantics  The  semantics  of  receivers  are 
behaviorally  defined  in  terms  of  events  in  the  actor  message-passing  model. 

All  messages  in  PLASMA  are  received  through  patterns  which  should  be  kept  quite  simple 
Writine  complicated  patterns  results  in  tortuous  obscure  code.  Simple  patterns  are  a good  way  to 
bind  identifiers  to  values  Pattern  matching  in  PLASMA  is  a generalization  of  the  lambda  calculus 
identifier  binding  mechanism.  The  semantics  of  receivers  is  behaviorally  defined  by  axioms  In  terms 
of  the  actor  message-passing  model. 

The  evaluation  of  a receiver  results  in  an  actor  which  has  as  Its  script  the  receiver  and  as  its 
acquaintances  the  actors  bound  to  the  free  identifiers  of  the  receiver  For  example  if  we  type 

(•  s [(3  ♦ 2)  (3  - 2)]) 

ther  we  will  create  an  actor  [5  ljwhich  is  called  a in  the  current  local  environment  in  which  we  are 
working.  If  we  then  type 

0 * idefine  1 to  be  an  actor  tohich 

(=>  [=*]  ;i ehcn  it  receive t a tequence  with  one  element  which  will  be  called  x 

(t  * •)))  repliet  with  g of  x and  • 

an  actor  will  be  created  which  has  [5  ljand  the  value  of  g as  its  acquaintances. 


X.5  — Conditionals 


Conditionals  in  PLASMA  take  two  standard  forms  which  are  closely  related.  One  form 
conditionally  tests  the  value  of  an  expression,  the  other  conditionally  tests  the  incoming  message  The 
first  is  known  as  the  ruUa  expression  and  has  the  form: 


(rulaa  an-axprassion 
(*>  pattern  | 
bod*,) 

(a>  pattern^ 
body 2 ) 


;the  rulet  for  the  actor  an-*xpr*t«ion  are 
;if  it  maichet  pattern,  then 
;repl y with  the  value  of  body, 
;elte  if  it  maichet  peftarn^  then 
reply  with  the  value  of  bodyg 


(■>  patt*rnn 
body,)) 


;elte  it  mutt  match  pattornn  to 
reply  with  the  value  of  bodyn 


The  expression  is  matched  against  the  successive  patterns  until  it  matches  one  of  them;  then  the 
corresponding  body  is  evaluated  In  the  environment  resulting  from  the  pattern  match  For  example. 


I 


\ .M* 
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(ruloa  (3  ♦ 4) 

(=>  («md)  ;the  pattern  {even)  mill  match  any  even  integer 

5) 

(=>  *n  ;the  pattern  »n  will  match  any  actor  and  bind  n to  that  actor 

(2  • n)))  ;retum  twice  the  value  of  n 

evaluates  to  14. 


PLASMA  uses  a similar  construct  (called  a cum  statement)  to  conditionally  dispatch  on  an 
incoming  message. 


(cat** 

(=>  pattern  j 
body | ) 

(s>  paltorng 
body 2 ) 


;rfce  catei  for  a menage  tent  to  this  actor  are 
;if  the  menage  matches  pattern  j then 
;reply  with  the  value  of  body | 
;elte  if  the  menage  matches  pattern2  then 
;reply  with  the  value  of  body 2 


(s>  pattern,, 
body,.)) 


;else  the  message  must  match  pattern,,  so 
; reply  with  the  value  of  bodyn 


A message  sent  to  an  expression  of  the  above  form  is  matched  directly  against  the  successive  patterns 
until  a match  is  found,  whereupon  the  corresponding  body  is  evaluated  in  the  environment  which 
results  from  the  match. 

For  example  the  following  actor  replies  with  yet  to  any  even  number  it  is  sent;  replies  with  no  to 
any  odd  number;  and  is  otherwise  not-applicable. 


(cat  at 

(=>  (even) 

y«») 

(e>  {odd) 
no)) 


X.6  — Definitions 

In  general,  typing  an  expression  of  the  form 

(name  2 definition) 


will  cause  PLASMA  to  do  its  subsequent  evaluations  In  an  environment  which  has  been  extended  by 
binding  namo  to  the  value  of  definition 
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For  example  the  normal  way  to  interactively  define  intagar-exponentiationwhlle  working  at  a 
console  would  be  to  type: 


(integer-exponentiation  9 
(a>  [=bas*  =expon*nt] 
(rul*<  *xpon*nt 
(s>  0 
1) 

(— > o o) 


;inf#g#r-#xponanlialion  it  defined  to  have  the  following  behavior 
^whenever  it  receivai  a sequence  of  two  arguments  called  bat*  and  exponent 

;the  mlei  for  the  exponent  are 
;if  it  it  0 then 
;reply  that  the  aniteer  it  1 
;elte  if  it  it  greater  than  0 then 


(bat*  * (int*g*r-*xpon*ntiation  bat*  (axponanl  - 1))))))) 

;t he  answer  it  the  base  limes  the  base  to  the  power  of  the  exponent  minus  I 


As  an  obvious  extension  to  our  notation  for  definitions  we  allow  a parenthesized  expression  on 
the  left  hand  side  of  a definition  For  example  we  can  define  integer  exponentiation  in  terms  of  an 
infix  operator  as  follows: 


((*baa*  to-integer-power  =*xpon*nt)  = 

(rul*t  exponent 
(=>  0 
1) 

(5>  o 0) 


;an  expression  of  the  form  (=bate  to-integer-power  =*xponent) 
;it  defined  by  the  following  behavior 
;lhe  rules  [or  the  exponent  are 
;if  it  it  0 then 
;lhe  answer  it  1 
;elte  if  it  it  greater  than  0 then 


(bate  * (bat*  to-integer-power  (exponent  - 1)))))) 

;the  answer  it  the  base  timet  the  bate  to  the  integer  power  of  the  exponent  minui  I 


Using  the  above  definition  (5  to-integer-power  3)evaluates  to  125  In  this  way  we  can  conveniently 
define  new  kinds  of  syntactic  forms 


MUTUALLY  REFERENTIAL  DEFINITIONS  are  easy  to  make  using  the  reserved  symbol  let  as 
follows: 


(/«> 

(name j s Dj) 

(nameg  = Dg) 

(nam*n  = D,,) 
then 
body) 

which  evaluates  body  in  an  environment  with  each  nam*j  bound  to  the  value  of  Dj.  The  equations  are 
mutually  referential  in  that  any  occurrence  of  a namoj  within  a D*  refers  to  0j. 

As  a special  case  of  the  let  construct  we  use 


(name  * definition) 
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as  an  abbreviation  for 
(lei 

(name  s definition) 

I hen 
name) 


Self -referential  definitions  are  very  useful  in  defining  iterative,  recursive,  and  co-routine  control 
structures.  They  are  also  useful  in  defining  data  structures  that  need  to  know  about  themselves. 

At  this  point,  we  have  enumerated  all  the  ways  to  bind  identifiers  in  PLASMA.  Note  that  the 
definition  of  every  symbol  is  lexically  scoped  and  that  there  are  no  ’global  variables’ 


X.7  — Unpack 


We  will  often  make  use  of  an  extremely  useful  operator  for  sequences  and  collections  called 
UNPACK  which  is  abbreviated  as  an  exclamation  point:  lexpretsioms  always  equivalent  to  writing  out 
all  of  the  elements  of  the  expression  individually.  Thus  if  sis  bound  to  the  sequence  [3  4 5],  then  the 
value  of  [1  2 !s]is  [1  2 3 4 5]  Thus  if  the  sequence  [10  20  30  40  50]is  matched  against  the  pattern 
[=*  -V  !=*].  then  xwill  be  bound  to  10,  ywill  be  bound  to  20,  and  xwill  be  bound  to  [30  40  50]  in  the 
environment  which  results  from  the  match.  Unpack  is  in  essence  the  inverse  of  sequence  brackets 

The  unpack  operator  neatly  cleans  up  the  confusion  In  LISP  between  different  ways  to  construct 
lists.  Considering  analogies  between  LISP  lists  and  PLASMA  sequences,  the  following  similarities  hold: 


[x  y x] 

is  analogous  to 

(list  x y x) 

I"  8x1 

is  analogous  to 

(con*  x y) 

t! * y] 

is  analogous  to 

(append  x (list  y)) 

I!*  8x1 

is  analogous  to 

(append  x y) 

The  chief  benefit  of  the  unpack  notation  is  that  the  programmer  no  longer  needs  to  concentrate 
on  how  to  construct  the  structure  by  deciding  whether  to  use  CONS,  LIST,  or  APPENO.  Instead  she  can 
concentrate  on  what  the  structure  should  be  by  wrltting  a pattern  of  what  it  should  look  like.  For 
example  the  following  PLASMA  expression 


[!•  [b  !c  d]  !•] 

has  the  following  LISP  analog 
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(append 

a 

(com 

(com 

b 

(append  c dial  d))) 
a)) 


X.8  — Use  of  Sequences 

Sequences  are  a useful  mechanism  for  the  implementation  of  the  kind  of  dialogues  needed  in  the 
implementation  of  knowledge-based  systems.  They  provide  a useful  common  interface  for  co-routine 
control  structures.  We  shall  bind  the  elements  and  sub-sequences  using  pattern  matching.  The 
following  pattern  will  bind  I to  the  first  element  of  a sequence  and  r to  the  rest. 

[*♦  !»r] 

For  example  if  a is  bound  to  the  sequence  [14  3 105]thrn  typing  the  following  expression  in  PLASMA 

( match  [af  Jar]  to  a) 


will  bind  I to  14  and  bind  r to  [3  105]. 


As  an  example  of  the  use  of  sequences,  we  define  the  function  sum-of  which  calculates  the  sum  of 
all  the  elements  in  a sequence: 


(sum -of  = 

(«>  [athe-tequence] 

(rules  the -sequence 

(*>  n 

0) 

(s>  [=the-next  jathe-rest] 

(the-next  ♦ (sum-of  the-rest)))))) 

For  example  (sum-o»  [1  4 9])evaluates  to  14. 

It  is  easy  to  build  sequences.  For  example 
consecutive  decreasing  squares. 


tdefine  the  function  lum-of 
;lo  receive  a sequence 
the  rule t for  the  sequence  are 
;if  the  sequence  is  empty 
;then  the  sum  it  0 
;eise  bind  the  nett  and  the  rest 
;lhen  return  the  next  plus  the  sum  of  the  rest 


following  definition  defines  finite  sequences  of 
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(•*qu*nc*-of-«quar*s  a 
(*>  [«n] 


(rul««  n 
(a>  0 

U) 

<*>  0 0) 

t(n  * ft)  !(a*qu*nca-of-t9uarM  (n  - 1))])))) 

;th«  auwor  it  a wiifc  n2 


;the  rule*  for  n am 
;if  it  it  0 thorn 
;thr  antwer  it  the  empty  teqoettce 
;olto  if  it  it  greater  thorn  0 them 

followed  the  tqueret  for  n miimt  1 


For  example  typing  the  following  expression  into  PLASMA 


(match  [■first  !»ra*t]  to  (t*quenc*-ofnquar*a  4)) 

results  in  binding  first  to  the  value  16  and  binding  r*st  to  the  value  (9  4 1J.  Thus 
(tum-of  (toquonco-of-tquorot  4))evaluates  to  30. 


X.9  — Delay 

For  many  applications,  it  is  more  efficient  to  generate  the  squares  in  the  sequence  of  squares 
incrementally  adopting  a "wait  and  see*  approach  as  to  whether  the  rest  of  the  elements  will  be  needed. 
To  this  end  we  introduce  the  delay  operator  which  delays  computation  of  the  value  of  expression  C 
until  the  value  is  needed  Suppose  that  v*  is  the  value  of  the  expression  (delay  E)  The  value  of  | is 
not  computed  until  the  actor  v*  is  sent  a message.  The  first  time  v#  is  sent  a message,  the  value  of  E is 
computed  and  remembered.  Thereafter  v*  behaves  exactly  like  the  value  of  E.  It  is  unreasonable* to 
delay  the  evaluation  of  any  expression  which  does  not  always  evlaluate  to  the  same  object. 

f 

The  delay  operator  can  be  used  to  refine  the  implementation  of  t*qu*nc*-of<*squer*t  to  produce 
an  incremental-version: 

(incr*m*nfal-t*qu*nc*>ef-squarM  a 
(a>  [an] 

(rui««  n 
(■>  0 
[]) 

(■>  0 0) 

[n2  f (delay  {incr*m*nfai*s*qu*nc*-ef-squarM  (n  - 1 )))])))) 

Typing  the  following  Into  PLASMA 

(male*  (=fl  !*rl]  to  (incremental t*qu«nc«-of~«qu«r««  10)) 
will  bind  fl  to  100  and  bind  rl  to  an  actor  which  is  behaviorally  equivalent  to 


♦ * 
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{delay  (incramanlal-taquanca-ot-squaras  9)) 

At  this  point  in  time  the  only  square  that  has  been  computed  is  the  square  of  10.  Typing 

{match  [sf2  !=r2]  to  rl) 

will  bind  f2  to  SI  and  bind  r2  to  an  actor  which  is  behaviorally  equivalent  to 

{delay  (incramanlal-taquanca-of-aquaraa  8)) 


X.IO  — Packagers 

PACKAGERS  are  a primitive  mechanism  in  PLASMA  for  packaging  actors  together.  They  are 
very  useful  for  packaging  up  the  parts  of  a message  For  example  the  notation  ...  xn]  for  a sequence 
is  really  just  syntactic  sugar  for  the  package  (tequence:  xj  ...  xn).  Thus  evaluation  of  an  ordinary 
function  call  of  the  form  (f  <*  [xj  ...  xn])sends  a package  which  is  the  sequence  of  arguments  to  f. 
However,  the  use  of  positional  notation  within  a sequence  for  the  components  of  a message  is  neither 
mnemonic  nor  secure.  The  packagers  of  PLASMA  allow  the  components  of  the  package  to  be  explicitly 
named  and  the  physical  representation  to  be  hidden  (for  reasons  of  efficiency  and  cleanliness).  They 
permit  all  of  the  components  of  the  package  which  are  of  interest  to  be  selected  in  parallel  and  the 
remainder  of  the  components  to  be  ignored  (for  reasons  of  modularity  and  extensibility).  Additionally, 
packagers  provide  for  both  the  privacy  and  security  of  messages  since  in  order  to  have  access  to  the 
contents  of  a package  constructed  by  a particular  packager,  it  is  necessary  to  have  access  to  that 
packager.  Packagers  are  the  primitive  authentication  mechanism  of  PLASMA  A packager  can  only  be 
taken  apart  by  the  packager  which  constructed  it. 

Tp  illustrate  the  use  of  packagers  we  shall  define  a packager  for  complex  numbers  First  we 
define  packagers  for  the  messages  to  which  complex  numbers  must  respond: 

( packager  (real-port?)) 

{packager  (imaginary-part?)) 

To  make  these  abbreviations  more  convenient  to  use  we  define  the  following  abbreviations: 

((r*al-part  =i)  - ;i he  real-part  of  z it  computed  by 

{(real-part?)  *)  z))  ; tending  a menage  atking  1 for  ill  real  part 

((imaginary-part  *i)  s ;i he  imaginary-part  of  z ii  computed  by 

(lima giltary- part?)  * > x))  ;tend  a menage  atking  z for  itt  imaginary  part 

Below  we  define  a packager  for  complex  numbers: 


V 


'V 
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C packager  ( complex : (real:  T)  {imaginary.  ?)) 

{define  a packager  for  complex  Humbert  with  real  and  imaginary  component! 
(■>  ( complex : (tmI:  m)  {imaginary  ay)) 

(CMI 


(*> 

(*> 

(*> 


(■> 


( real-part ?) 

x) 

{imaginary- part?) 

y) 

{plat:  ax) 
{complex: 


lif  atked  for  the  real  part  than 
{return  x 

{if  atked  for  the  imaginary  part  then 

return  y 

{if  atked  for  the  turn  with  t then 
return  a complex  number  with 
real  component  the  <am  of  x and  the  real  part  of  X 


{real:  (x  ♦ (rail-part  z))) 

{imaginary  (y  ♦ (imaginary-part  x))))) 

;and  imaginary  component  the  turn  of  y and  the  imaginary  part  of  a 


(limn*:  «x) 

( complex : 

{real:  ((x  * (rnal-part  z))  - (y  * (imaginary-part  x)))) 

{ imaginary  <(x  • (imaginary-part  *))  ♦ (y  * (raal -part  z))))))))) 


Notice  the  use  of  the  packager  complex:  both  to  construct  complex  numbers  and  to  take  them 
apart  into  their  real  and  imaginary  parts.  The  above  implementation  is  inefficient  because  of  all  the 
message  passing  involved  in  computing  the  values  of  (real-part  z)and  (imaginary-part  z)when  doing 
addition  and  multiplication  of  complex  numbers.  For  example  in  the  above  implementation  two  such 
messages  are  required  to  compute  the  sum  in  the  following  sub-expression  of  the  above  program: 

(complex: 

{real:  (x  ♦ (real-part  z))) 

(imaginary:  (y  ♦ (imaginary-part  z)))) 


We  will  demonstrate  how  the  efficiency  can  be  improved  in  a purely  mechanical  way  without 
diminishing  the  generality  of  the  implementation.  The  first  step  is  to  collect  statistics  of  executions  to 
determine  which  actors  are  very  frequently  sending  messages  to  other.  This  will  soon  reveal  that  the 
expression  (real-part  z)quite  often  results  In  sending  the  message  {real-part? ko  z where  z Is  of  the  form 

{complex:  {real:  rz)  {imaginary  iz)) 

This  suggests  that  special  code  for  this  case  might  be  generated  in-line  to  speed  up  the  execution. 
Obviously  the  expression  (raal-part  z)is  completely  equivalent  to 

(ruia*  z 

(s>  {complex:  (real:  = rz)  ( imaginary  :iz|) 

(raal-part  {complex:  (real:  rz)  (imaginary,  iz))  )) 

(el  to 

(raal-part  z))) 
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By  replacing  real-part  and  complex:  by  their  definition*  and  simplifying  we  obtain  the  following 
expression:  6 


-TV 


(rulM  x 

(*>  (complex:  (real:  art)  {imaginary.  »ix)) 
rx) 

(#/m 

(real -part  x))) 

By  performing  the  above  transformation  on  all  expressions  of  the  form  (rool-porl  z)and 
(imaginary-part  x)and  then  pulling  out  common  sub-expressions  the  following  more  efficient 
Implementation  of  the  packager  complex:  has  been  derived: 

{packager  ( complex : {real:  T)  ( imaginary  T)) 

;define  a more  efficient  packager  for  complex  namkert  milk  real  and  Imaginary  components 
(*>  ( complex : (real:  »x)  (imaginary  ay)) 

(caaoa 

(*>  (real-part?) 

X) 

(■>  (imaginary- part?) 

y) 

(*>  (plus:  *x) 

(ruiut  x 

(■>  (complex:  (real:  art)  (Imaginary  ail)) 

(complex: 

(real:  (x  ♦ rx)) 

(imafinory?  (y  ♦ lx)))) 

(alee 

( complex : 

(real:  (x  ♦ (real-part  x») 

(imaginary,  (y  ♦ (imaginary-part  x))»)» 

(*>  (times;  mg) 

(rules  x 

(■>  ( complex : (real:  *rx)  ( imaginary,  ait)) 

(complex: 

(real:  ((x  • rx)  - (y  * is))) 

(imaginary  ((x  * ix)  ♦ (y  * a)))) 

(else 

( complex : 

(real:  ((x  * (real-pert  x»  - (y  • (imaginary-part  x)))) 

(imaginary  ((x  * (imaginary -part  x))  ♦ (y  * (real-part  x)))))))))))) 


Note  that  PLASMA  is  ideally  suited  for  the  above  kind  of  optimization  by  In-line  substitution 
because  identifiers  in  PLASMA  (unlike  many  other  languages)  are  completely  transparent  An 
occurrence  of  Identifier  in  PLASMA  serves  only  to  name  the  actor  to  which  It  is  bound.  In-line 
substitution  is  not  always  valid  in  languages  like  LISP  13  because  of  the  SET  primitive  in  the  language. 


The  presence  of  a primitive  like  SET  (and  other  similar 
optimization  much  more  difficult. 


primitives  in  other  LISP-like  languages)  makes 


